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Preface 



In this volume you will find the lecture notes corresponding to the presen- 
tations given at the 3’’*^ summer school on Advanced Functional Programming, 
held in Braga, Portugal from September 12-19, 1998. 

This school was preceded by earlier ones in Bastad (1995, Sweden, LNCS 925) 
and Olympia, WA (1996, USA, LNCS 1129). The goal of this series of schools is 
to bring recent developments in the area of functional programming to a large 
group of students. The notes are published in order to enable individuals, small 
study groups, and lecturers to become acquainted with recent work in the fast 
developing area of functional programming. 

What made this school particularly interesting was the fact that all lectures 
introduced useful software, that was used by the students in the classes to get 
hands-on experience with the subjects taught. We urge readers of this volume to 
download the latest version of this software from the Internet and try to do the 
exercises from the text themselves; the proof of the program is in the typing. 

The first lecture, on Sorting Morphisms, serves as a gentle introduction to the 
things to come. If you have always been afraid of the word “morphism” , and you 
have been wondering what catamorphisms, anamorphisms, hylomorphims, and 
paramorphims were about, this is the paper to read first; you will discover that 
they are merely names for recursion patterns that occur over and over again when 
writing functional programs. The algorithms in the paper are all about sorting, 
and since you are likely to know those algorithms by heart already, seeing them 
structured and analyzed in a novel way should serve as a motivation to read on 
to the second lecture. 

The second lecture, on Generic Programming, is almost a book in a book. 
The notes can be seen as the culminating point of the STOP-project, sponsored 
by the Dutch government at the end of the 80’s and the beginning of the 90’s. Its 
overall goal was the development of a calculational way of deriving programs. The 
project has provided deeper insight into real functional programming and into 
the theory behind many things commonly written by functional programmers. 
One of the main achievements of the project has been to make people aware 
of the fact that many algorithms can be described in a data-independent way. 
The PolyP system introduced in these notes is one of the translations to the 
Haskell-world of this theoretical underpinning. 

The third lecture, on Generic Program Transformation, can also be seen as 
an application of the theory introduced in lecture two. Many efficiency-improving 
program transformations can be performed in a mechanical way, and these would 
not have been possible without insight into the correctness of such transforma- 
tions gained in the lecture on Generic Programming. 

The fourth lecture, on Designing and Implementing Combinator Languages, 
introduces an easy to write formalism for writing down the catamorphisms intro- 
duced in earlier chapters. It is shown how quite complicated catamorphisms, that 
at first sight seem rather forbidding by making extensive use of higher-order do- 
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mains, can actually be developed in a step-wise fashion, using an attribute gram- 
mar view; it is furthermore shown how to relate this way of programming with 
concepts from the object-oriented world thus making clear what the strengths 
and weaknesses of each world are. 

The fifth lecture, titled Using MetaML: A Staged Programming Language, 
introduces the concept of partial evaluation. It serves as another instance of 
the quest for “the most generic of writing programs at the lowest cost”. The 
staging techniques show how costs that were introduced by adding extra levels 
of abstraction, may be moved from run-time to compile-time. 

It has been common knowledge to users of modern functional languages that 
the type system can be a great help in shortening programs and reducing errors. 
In the extreme one might see a type as a predicate capturing the properties 
of any expression with that type. In the sixth lecture on Cayenne - Spice up 
your Programming with Dependent Types it is shown in what direction functional 
languages are most likely to develop, and what may be expected of the new type 
systems to be introduced. 

The last lecture, titled Haskell as an Automation Controller, shows that 
writing functional programs does not have to imply that one is bound to remain 
isolated from the rest of the world. Being able to communicate with software 
written by others in a uniform way, is probably one of the most interesting 
new developments in current computer science. It appears that the concept of a 
monad together with the Haskell typing rules, is quite adequate to describe the 
interface between Haskell programs and the outer world. 

Finally we want to thank everyone who contributed to this school and made 
it such a successful event: sponsors, local system managers, local organizers, 
students, and last but not least the lecturers. We are convinced that everyone 
present at the school enjoyed this event as much as we did, and we all hope that 
you will feel some of the spirit of this event when studying these lecture notes. 
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Abstract. Sorting algorithms can be classified in many different ways. 
The way presented here is by expressing the algorithms as functional 
programs and to classify them by means of their recursion patterns. These 
patterns on their turn can be classified as the natural recursion patterns 
that destruct or construct a given data-type, the so called cata- and 
anamorphisms respectively. We show that the selection of the recursion 
pattern can be seen as the major design decision, in most cases leaving 
no more room for more decisions in the design of the sorting algorithm, 
ft is also shown that the use of alternative data structures may lead to 
new sorting algorithms. 

This presentation also serves as a gentle, light-weight, introduction into 
the various morphisms. 



1 Introduction 

In this paper we present several well known sorting algorithms, namely insertion 
sort, straight selection sort, bubble sort, quick sort, heap sort and merge sort (see 
e.g. [8,11]) in a non-standard way. We express the sorting algorithms as func- 
tional programs that obey a certain pattern of recursion. We show that for each 
of the sorting algorithms, the recursion patterns forms the major design decision, 
often leaving no more space for additional decisions to be taken. We make these 
recursion patterns explicit in the form of higher-order functions, much like the 
well-known map function on lists. 

A different approach to the classification of sorting algorithms can be found in 
[3], where formal specifications of sorting functions are made more and more 
specific in a step-wise fashion, thus deriving the structure of merge sort, quick 
sort, insertion sort and selection sort. 

In order to reason about recursion patterns, we need to formalize that notion. 
Such a formalization is already available, based on a category theoretical mod- 
eling of recursive data types as can e.g. be found in [4,9]. In [2] this theory is 
presented together with its application to many algorithms, including selection 
sort and quicksort. These algorithms can be understood however only after ab- 
sorbing the underlying category theory. There is no need to present that theory 
here. The results that we need can be understood by anyone having some basic 
knowledge of functional programming, hence we repeat only the main results 
here. These results show how to each recursive data type a number of mor- 
phisms is related, each capturing some pattern of recursion which involve the 
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recursive structure of the data type. Of these morphisms, we use the so called 
catamorphism, anamorphism, hylomorphism and paramorphism on linear lists 
and binary trees. The value of this approach is not so much in obtaining a nice 
implementation of some algorithm, but in unraveling its structure. 

This presentation gives the opportunity to introduce the various morphisms in 
a simple way, namely as patterns of recursion that are useful in functional pro- 
gramming, instead of the usual approach via category theory, which tends to be 
needlessly intimida ting for the average programmer. 

In this paper, we assume that all sorting operations transform a list 1 into a list 
s that is a permutation of 1, such that the elements of s are ascending w.r.t. to 
a total ordering relation <. Moreover, we assume the existence of an equivalence 
relation == on the elements, such that for all elements a, b, either a<b, a==b 
or b<a. 

We express the sorting algorithms in the functional language Hugs [7], which 
is a dialect of Haskell [6]. We assume that the reader is familiar with, but not 
necessarily an expert in, functional programming. 

This paper is organized as follows. In Sect. 2 we present the morphisms on the 
list data type and show that insertion sort, selection sort and bubble sort can be 
expressed in terms of these morphisms. In Sect. 3 we present the leaf tree data 
type and show how merge sort can be expressed as a morphism over that data 
type. In Sect. 4 we present the binary tree data type with its morphisms, which 
are used to express both quick sort and heap sort. In Sect. 5 paramorphisms on 
lists are presented, which can be used to express the recursion pattern of several 
auxiliary functions used by the different sorting algorithms. We show in Sect. 
6 that rose trees form a generalization of lists, binary trees and leaf trees. This 
fact enables a derivation of pairing heap sort and reveals a novel generalization 
of quick sort. It also opens the door for a taxonomy of algorithms, based on a hi- 
erarchy of data structures and on recursion patterns over those data structures. 
Section 7 presents the conclusions of this paper. 

2 Morphisms on Lists 

The list data type can be described by the following pseudo data type definition 
in Haskell. 

data [x] = [] 

I X : [x] 

In this section we present three recursion patterns over this data type, and 
show how insertion sort, selection sort and bubble sort can be expressed by means 
of these recursion patterns. 

2.1 The List Catamorphism 

A catamorphism on a type T is a function of type T ^ U that destruct and 
object of type T according to the structure of T, calls itself recursively of any 
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components of T that are also of type T and combines this recursive result with 
the remaining components of T to a U . 

A simple example is the function that computes the product of a list of 
integers: 



prod [] =1 

prod (x:l) = x * prod 1 



A list catamorphism can thus be characterized by two components (a,f), 
corresponding to the two forms of the list type. The first is a part that maps the 
empty list onto a U . This is just the constant a (for prod this is 1). A non-empty 
list can be destructed into a head h and a tail t. The tail t is recursively mapped 
onto a u by rec t and then combined with the head by means of the expression 
f h (rec t), where f is the second part of the catamorphism. For prod this 
is (*). 

We can present this structure in a diagram where the nodes form the types of 
the (intermediate) results and the edges the mappings between them. 



\ / 



\ 


destruct [x] 


x,[x] 


1 


recurse 


X, u 
/ 


construct m 



u 

Recursive functions over lists that have this structure can be written by 
means of a higher order function of (a,f ) that captures this recursive patterns. 
As this recursion pattern is generally called eatamorphism (Kara means down- 
wards), we call this higher order function list_cata. As described above, it 
returns a on the empty list and applies f to the head and the recursive call 
on the tail, the more experienced reader will recognize this function as the well 
known f oldr. 

The (a,f) is usually called an algebra, more specifically a list algebra. We 
abbreviate its type by List_alg. 



> type List_alg x u = (u, x->u->u) 



> list_cata : : List_alg x u -> [x] -> u 

> list_cata (a,f) = cata where 

> cata [] = a 

> cata (x:l) = f x (cata 1) 



With this definition we can rewrite prod as follows: 



> prod = list_cata (1, (*)) 
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It can be observed that this catamorphism replaces the empty list by a and 
the non-empty list constructor (:) by f . This is what a catamorphism does in 
general: replacing the constructors of a data type by other functions. As a conse- 
quence, recursive elements are replaced by the application of the catamorphism 
to them, i.e. 1 is replaced by cata 1. 

Exercise 1: Write the list reversal function as a list catamorphism. 



2.2 The List Anamorphism 

Apart from a recursion pattern that traverses a list, we can specify a converse 
one that constructs a list. A simple example is the function that constructs the 
list [n,n-l . . 1] . 

count 0 = [] 

count n = n : count (n-1) 



An anamorphism over a type T is a function of type U ^ T that destructs 
the U in some way into a number of components. On the components that are of 
type U, it applies recursion to convert theme to T’s. After that it combines the 
recursive results with the other components to a T, by means of the constructor 
functions of T. 

The structure of this pattern for the list type can be obtained by inverting 
the catamorphism diagram above. 



u 



/ 

\ 



\ 


destruct u 


X, u 


1 


recurse 


x,[x] 

y 


construct [x] 



X 

We need some destructor function of u that tells us whether to map u onto 
the empty list, or to destruct it, be means of some function f into the head of 
the resulting list x and another u. This other u can then recursively be mapped 
onto a list, which forms the tail of the final result. 

To this end, we define use the type that represents the disjoint sum of to values. 



data Either a b = Left a I Right b 

Again, this pattern of recursion can be captured in a higher order function. 
As this recursion pattern is generally called anamorphism {ai'a means upwards), 
we call this higher order function list_ana. 

The type u-> Either () (x,u) is usually called a co-algebra, more specifi- 
cally a list co-algebra. We abbreviate this type by List_coalg. 
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> type List_coalg u x = u -> Either () (x,u) 

> list_ana : : List_coalg u x -> u -> [x] 

> list_ana a = ana where 

> ana u = case a u of 

> Left _ -> [] 

> Right (x,l) -> X : ana 1 

The function count can be rewritten as: 

> count = list_ana destruct_count 

> destruct_count 0 = Left () 

> destruct_count n = Right (n,n-l) 

Exercise 2: Write a prime number generator as a list anamorphism. 



2.3 The List Hylomorphism 

Given a general way to construct a list and to destruct one, we can compose 
the two operations into a new one, that captures recursion via a list. For some 
philosophical reason, this recursion patterns is called hylomorphism {v\rj means 
matter) . 

The list hylomorphism can be defined as 
list_hylo (a,c) = list_cata c . list_ana a 

As an example, we could define the factorial function as 
f ac = prod . count, or more explicitly as: 

fac = list_cata (!,(*)) . list_ana destruct_count 

This straightforward composition forms an intermediate list, which appears 
to be unnecessary as the following diagrams exhibits, 
u 



/ 


\ 


destruct u 










X, u 












1 

x,[x] 


recurse 


u 










/ 


\ 


destruct u 


\ 


/ 


construct [x] 




X, u 




x] 






1 


recurse 


/ 


\ 

x,[x] 


destruct [x] 




X, V 




\ 


/ 


construct v 




1 


recurse 


V 








X, V 










\ 


/ 


construct v 









V 
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Instead of construction the list in the middle, we can immediately map the 
(x,u)-pair onto the (x,v)-pair by recursively applying the hylomorphism to 
the u. 

The implementation is obtained from the list_ana by replacing the empty 
list by a and the list constructor ( : ) by f . 

> type List_hylo u x v = (List_coalg u x, List_alg x v) 

> list_hylo : : List_hylo u x v -> u -> v 

> list_hylo (d,(a,f)) = hylo where 

> hylo u = case d u of 

> Left _ -> a 

> Right (x,l) -> f X (hylo 1) 

Applying this to the factorial function, it can be written as: 

> fac = list_hylo (destruct_count , (1,(*))) 

Substitution of listJiylo and destruct_count then leads to the usual def- 
inition of fac: 

fac 0 = 1 

fac n = n * fac (n-1) 

Exercise 3: Write the function a;” as a list hylomorphism. 

2.4 Insertion Sort 

We can use the list_cata recursion pattern to sort a list. In order to analyze 
the structure of such a sorting algorithm, we first draw a little diagram. 



X : 1 





destruct 


H [ 


1 


1 






\ recurse 


m [ 


sort 1 


1 

insert 



insert x (sort 1) 



The catamorphism must destruct a list x:l into a head x and a tail 1, by 
virtue of its recursive structure. Next it is applied recursively to the tail, which 
in this case means: sorting it. So we are left with a head x and a sorted tail. 
There is only one way left to construct the full sorted list out of these: insert x 
at the appropriate place in the sorted tail. We see that apart from the recursion 
pattern, we are left with no more design decision: the resulting algorithm is an 
insertion sort. 
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> insertion_sort 1 = list_cata ([], insert) 1 where 

> insert x [] = [x] 

> insert x (a:l) I x < a = x:a:l 

> I otherwise = a : insert x 1 



Observe that insert x is a recursive function over lists as well. As it does 
not correspond to the recursive structures introduced so far, we postpone its 
treatment until Sect. 5.2. 



2.5 Selection Sorts 



In applying the anamorphism recursion pattern to sorting, we are faced with the 
following structure. 




extract minimum 

recurse 

construct 



First of all, the unsorted list 1 is mapped onto an element m and a remainder 
1 ’ . This remainder is sorted by recursion and serves as the tail of the final result. 
From this structure, we can deduce that m must be the minimum of 1 and 1 ’ 
should equal some permutation of 1 with this minimum removed from it. It is the 
permutation which gives us some additional design freedom. Two ways to exploit 
this freedom lead to a straight selection sort and a bubble sort respectively. Here 
we abstract from the way of selection and define the general selection sort as: 



> selection_sort extract = list_ana select where 

> select [] = Left () 

> select 1 = Right (extract 1) 



Straight Selection Sort. When we first compute the minimum of 1 and then 
remove it from 1, maintaining the order of the remaining elements, we obtain a 
straight selection sort. It has the following recursive structure. 
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1 








m 


remove m 1 






m 


sort (remove m 1) 






m 


: sort (remove m 1) 



select minimum 

recurse 

construct 



Its implementation as an anamorphism is as follows. 

> straight_selection_sort 1 = selection_sort extract 1 where 

> extract 1 = (m, remove ml) where m = minimum 1 

> remove x [] = [] 

> remove x (y:l) I x == y =1 

> I otherwise = y : remove x 1 

Observe that remove x is a recursive function over lists as well. As it does 
not correspond to the recursive structures introduced so far, we postpone its 
treatment until Sect. 5.3, where we also give an implementation of minimum as 
a catamorphism as well. 



Bubble Sort. Selection sort seems a little too expensive as select traverses 
the list twice, once for obtaining the minimum and once for removing it. We can 
intertwine these to operations to let the minimum ’bubble’ to the head of the 
list by exchanging elements and then split the minimum and the remainder. 




bubble 

recurse 

construct 



> bubble_sort 1 = selection_sort bubble 1 where 

> bubble [x] = (x,[]) 

> bubble (x:l) = if X < y then (x,y:m) else (y,x:m) where 

> (y,m) = bubble 1 

Observe that bubble is a recursive function over lists as well. It appears to 
be a catamorphism, as the following alternative definition shows: 
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> bubble_sort’ 1 = selection_sort bubble 1 where 

> bubble (x:l) = list_cata ((x,[]),bub) 1 

> bub X (y,l) = if X < y then (x,y:l) else (y,x:l) 



3 Leaf Trees 

The sorting algorithms that can be described by list-based recursion patterns 
all perform linear recursion and as a result behave (at least) quadratically. The 
0(nlogri.) sorting algorithms like quick sort and merge sort use at least two 
recursive calls per recursion step. In order to express such a recursion pattern 
we need some binary data structure as a basis for the different morphisms. In 
this section we concentrate on leaf trees with the elements in their leaves. The 
next section treats binary trees with the elements at the branches. 

One form of binary trees are so-called leaf-trees. These trees hold their elements 
on their leaves. The leaf-tree data type is given by: 

> data LeafTree x = Leaf x 

> I Split (LeafTree x) (LeafTree x) 



3.1 The Leaf- Tree Catamorphism 

The structure of the leaf-tree catamorphism is completely analogous to that 
of the list catamorphism. First destruct the tree, recurse on the sub-trees and 
combine the recursive results. 

An example is the sum of all elements in a leaf tree: 

tree_sum Leaf x = x 

tree_sum (Split 1 r) = tree_sum 1 + tree_sum r 

The leaf-tree catamorphism needs a function on the element, rather than a 
constant, to construct its non-recursive result. This corresponds to the following 
diagram, where T stands for BinTree x. 

The recursion pattern diagram is: 

T 



/ 


\ 


destruet T 


X 


T,T 




1 


II 


recurse 


X 


u,u 




\ 


/ 


construct u 



u 

Capturing the recursion pattern in a higher order function leaf tree_cata, 
gives the following definition (again, just replace the tree constructors Leaf and 
Split by other functions, fl and fs respectively). 
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> type Leaftree_alg x u = (x -> u, u -> u -> u) 

> leaf tree_cata : : Leaftree_alg x u -> LeafTree x -> u 

> leaf tree_cata (fl,fs) = cata where 

> cata (Leaf x) = fl x 

> cata (Split 1 r) = fs (cata 1) (cata r) 

Using the function leaf tree_cata, we can define tree_sum as: 

> tree_sum = leaf tree_cata (id, (+)) 



3.2 The Leaf- Tree Anamorphism 

The structure of the leaf-tree anamorphism is analogous to that of the list 
anamorphism. First decide by means of a destructor d between the tree construc- 
tors to be used (Tip or Branch). This results in an element or in two remaining 
objects which are recursively mapped onto two trees. Then combine the element 
or these subtrees. 

An example is the construction of a Fibonacci tree: 

fib_tree n 

I n < 2 = Leaf 1 

I otherwise = Branch (fib_tree (n-1)) (fib_tree (n-2)) 

The anamorphism procedure corresponds to the following diagram. 



u 

/ 


\ 


destruct u 


X 


u,u 




1 


1 1 


recurse 


X 


T,T 




\ 


/ 


construct T 



T 

Capturing the recursion pattern in a higher order function leaftree^na, 
gives the following definition. 

> type Leaf tree_coalg u x = u -> Either x (u,u) 

> leaftree_ana : : Leaf tree_coalg u x -> u -> LeafTree x 

> leaftree_ana d = ana where 

> ana t = case d t of 

> Left 1 -> Leaf 1 

> Right (l,r) -> Split (ana 1) (ana r) 
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Rewriting f ib_tree with this higher order function gives: 

> fib_tree = leaftree_ana destruct_fib 

> destruct_fib n I n < 2 = Left 1 

> I otherwise = Right (n-l,n-2) 



3.3 The Leaf- Tree Hylomorphism 

As expected, the leaf-tree hylomorphism can be obtained by composing the ana- 
and the catamorphism. 

An example is the Fibonacci function 
f ib = tree_sum . f ib_tree, or more explicitly as: 

fib = leaf tree_cata (id,(+)) . leaftree_ana destruct_fib 

Again the tree in the middle need not be constructed at all as the following 
diagram illustrates. We can apply recursion to map the two u’s into v’s, without 
constructing the trees. 



/ 


\ 


destruct u 


a 


u,u 




1 


1 1 


recurse 


a 

\ 


v,v 

/ 


construct v 



V 

and its implementation with no further comment: 

> type Leaf tree_hylo u x v 

> = (Leaf tree_coalg u x, Leaftree_alg x v) 

> leaf tree_hylo : : Leaf tree_hylo u x v -> u -> v 

> leaf tree_hylo (d,(fl,fs)) = hylo where 

> hylo t = case d t of 

> Left 1 -> fl 1 

> Right (l,r) -> fs (hylo 1) (hylo r) 

Using this definition of leaf treeJiylo we can define the Fibonacci 
function as: 

> fib = leaftree_hylo (destruct_f ib, (id,(+))) 

This can of course be simplified by substituting the functions leaf treeJiylo 
and destruct jfib into: 
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fibn|n<2 =1 

I otherwise = fib (n-1) + fib (n-2) 

Exercise 4^ Write the factorial function as a leaf -tree hylomorphism. 
Exercise 5: Write the function a;” as a leaf-tree hylomorphism. What is its 
complexity? Can you write it as a hylomorphism with O{logn) complexity? 



3.4 Merge Sort 

The leaf-tree hylomorphism can be used to sort lists via leaf-trees. The recursion 
pattern can be depicted as follows. 




split 

recurse 

merge 



In the recursive case, the list is split into two sub-list, which are sorted, and 
then combined. The main choice left here is to make the sub-lists dependent or 
independent of the elements of the other sub-lists. 

When we assume independence, the combination of the recursive results must 
merge two unrelated sorted lists, and we obtain merge sort. 

The choice of two sub-lists which are dependent on each other does not buy 
us much. If we assume that we can only apply an ordering and an equality 
relation to the elements, we can’t do much more than separating the elements 
into small and large ones, possibly w.r.t. to the median of the list (which would 
yield quicksort). We do not pursue this way of sorting any further here. 

The implementation of merge sort as an hylomorphism from lists, via leaf-trees, 
onto lists is given below. The non- recursive case deals with lists of one element. 
The empty list is treated separately from the hylomorphism. 

> merge_sort [] = [] 

> merge_sort 1 = leaf tree_hylo (select , (single , merge) ) 1 

> where 

> single X = [x] 

> merge (x:xs) (y:ys) I x < y = x : merge xs (y:ys) 

> I otherwise = y : merge (x:xs) ys 

> merge [] m = m 

> merge 1 [] = 1 

> select [x] = Left x 

> select 1 = Right (split 1) 
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The function split splits a list into two sub- list, containing the odd and 
even elements. We present it here in the form of a list catamorphism. 

> split = list_cata (([],[]),f) where 

> f X (l,r) = (r,x:l) 



4 Binary Trees 

Another form of binary trees are trees that hold the values at their branches 
instead of their leaves. This binary tree data type is defined as follows. 

> data BinTree x = Tip 

> I Branch x (BinTree x) (BinTree x) 



4.1 The Tree Catamorphism 

The structure of the tree catamorphism should be straight-forward now. First 
destruct the tree, recurse on the sub-trees and combine the element and the 
recursive results. This corresponds to the following diagram, where T stands for 
BinTree x. 

destruct T 

recurse 

construct u 
u 

Capturing the recursion pattern in a higher order function bintree_cata, 
gives the following definition. 

> type Bintree_alg x u = (u, x -> u -> u -> u) 

> bintree_cata : : Bintree_alg x u -> BinTree x -> u 

> bintree_cata (a,f) = cata where 

> cata Tip = a 

> cata (Branch x 1 r) = f x (cata 1) (cata r) 

Observe again that a catamorphism replaces constructors (Tip by a and 
Branch by f) and recursive elements by recursive calls (l by cata 1 and r by 
cata r). 



/ \ 

x,T,T 

I I 

x,u,u 

\ / 
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4.2 The Tree Anamorphism 

The binary tree catamorphism is again obtained by reversing the previous one. 

u 



/ \ 



destruct m 



x,u,u 

1 1 



+ x,T,T 

\ / 



recurse 
construct T 



T 



Capturing the recursion pattern in a higher order function bintree_ana, 
gives the following definition. 



> type Bintree_coalg u x = u -> Either () (x,u,u) 

> bintree_ana : : Bintree_coalg u x -> u -> BinTree x 

> bintree_ana d = ana where 

> ana t = case d t of 

> Left _ -> Tip 

> Right (x,l,r) -> Branch x (ana 1) (ana r) 



4.3 The Tree Hylomorphism 

The binary tree hylomorphism should be straightforward now. We present only 
its diagram 



destruct u 
rccursc 
construct v 

The implementation of the binary tree hylomorphism is obtained from the 
anamorphism by replacing Tip by a and the Branch constructor by f . 

> type Bintree_hylo u x v = (Bintree_coalg u x, Bintree_alg x v) 

> bintree_hylo : : Bintree_hylo u x v -> u -> v 

> bintree_hylo (d,(a,f)) = hylo where 

> hylo t = case d t of 

> Left _ -> a 

> Right (x,l,r) -> f X (hylo 1) (hylo r) 



u 

/ \ 

x,u,u 

1 1 

x,v,v 

\ / 

V 
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Exercise 6: Write the factorial function as a binary tree hylomorphism. 
Exercise 7; Write the function a:" as a binary tree hylomorphism. What is 
its complexity? 

Exercise 8: Write the towers of Hanoi as a binary tree hylomorphism. 



4.4 Quicksort 



We can apply the binary tree hylomorphism recursion pattern to sorting by 
sorting a list via binary trees (which are never really constructed of course). The 
following diagram exhibits the recursion pattern. 



s 





11 








sort 11 





12 



sort 12 



join X (sort 11) (sort 12) 



split 

recurse 

join 



A list 1 is split into an element x and two other lists 11 and 12. These lists 
are sorted by recursion. Next x and the sorted sub-lists are joined. We are left 
with a two design decisions here. 

— The choice of x. Sensible choices here are the head of the list, using the 
structure of the list, or the minimum or median of the list, exploiting the 
ordering relation. If we take the minimum, we obtain a variant of heap 
sort. A derivation of heap sort is given in Sect. 4.5. For quicksort, we 
choose to take the head of the list. Taking the median is left to the reader. 

— The choice of the two sub-lists. An essential choice here is to make them 
dependent on the element x or not. If not, there seems to be no particular 
reason to separate x. If we do not use the head x at all, the algorithm 
obeys a different recursion pattern, which we treat in Sect. 3. 

The remaining option, making the sub-lists depend on x, still leaves some 
choices open. The most natural one seems to let them consists of the ele- 
ments that are smaller than, respectively at least x, exploiting the ordering 
relation. This can be done for x being either the head or the median of 
the list, where the latter gives a better balanced algorithm with a superior 
worst case behavior. We will take the head for simplicity reasons here. 

Given the decisions that we take x to be head of the list and split the tail 
into small and large elements w.r.t. to x, the only way in which we can combine 
the sorted sub-lists with x is to concatenate them in the proper order. 
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X : 1 



I X I 
I X I 



small 




large 






sort small 




sort large 



sort small ++ [x] ++ sort large 



split 

recurse 

join 



The final result is an implementation of quicksort as a hylomorphism from 
lists, via trees, onto lists. 

> quick_sort 1 = bintree_hylo (split, ([], join)) 1 where 

> split [] = Left 0 

> split (x:l) = Right (x,s,g) where (s,g) = partition (<x) 1 

> join xlr =l++x:r 

The function partition which splits a list into two lists w.r.t. to some pred- 
icate p appears to be a list catamorphism. 

Exercise 9: Write the function partition as a list catamorphism. 



4.5 Heap Sort 

In this section we analyze the recursion pattern of heap sort. This algorithm 
operates by first constructing a binary tree that has the so called heap property, 
which means that for such a tree Branch m 1 r, m is the minimum element in 
the tree. The two sub-trees 1 and r must also have the heap property, but are 
not related to each other. 

After constructing such a heap, the heap is mapped onto a sorted list. Therefore, 
the definition of heap sort is simply: 

> heap_sort 1 = (heap21ist . Iist2heap) 1 

Such a tree is transformed into a sorted list in the following way, where 
combine 1 r combines two heaps into a new one. It is clearly a list anamorphism. 



Branch xlr 








1 ^ 1 


combine 1 r 






1 ^ 1 


sort (combine 1 r) 






X 


: sort (combine 1 r) 



extract 

recurse 



construct 
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Thus, heapsort can be implemented as below, leaving list2heap, which 
transforms an unsorted list into a heap, to be specified. The b@ (Branch x 1 r) 

construction in Hugs matches an argument to the pattern Branch x 1 r as 

usual, but also binds the argument as a whole to b. 

> heap21ist 1 = list_ana extract 1 where 

> extract Tip = Left () 

> extract (Branch x 1 r) = Right (x, combine 1 r) 

> combine : : Ord a => BinTree a -> BinTree a -> BinTree a 

> combine t Tip = t 

> combine Tip t = t 

> combine b@ (Branch x 1 r) c@ (Branch y s t) 

> I X < y = Branch x 1 (combine r c) 

> I otherwise = Branch y (combine b s) t 

Three recursion patterns that could be applicable to the function list2heap 
are a list catamorphism, a tree anamorphism, or a hylomorphism over some ad- 
ditional data type. Let us analyze the recursion pattern of such a function, where 
we assume that we use list2heap recursively in a binary tree pattern (note that 
this a design decision), more particularly, let us choose the tree anamorphism. 
The other options work just as well, but for simplicity, we do not persue them 
here. 




extract minumum and split rest 

reeurse 

construet tree 



The decomposition is a variant of bubble: it should not only select the min- 
imum but also split the remainder of the list into two sub-lists of (almost) equal 
length. This bubbling is once more a list catamorphism. 

> list2heap 1 = bintree_ana decompose 1 where 

> decompose [] = Left () 

> decompose 1 = Right (bubble 1) 

> bubble (x:l) = list_cata ( (x, [],[]), bub) 1 

> bub X (y,l,r) = if x < y then (x,y:r,l) else (y,x:r,l) 

Thus, heap sort can be written as the composition of a binary tree anamor- 
phism and a list anamorphism. 
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5 Paramorphisms 

Several sub-functions, like insert and remove used above where almost cata- 
morphisms on lists. They deviate by the fact that in the construction of the 
result, they do not only use the recursive result of the tail, but also the tail 
itself. This recursion pattern is known as paramorphism^ after the Greek word 
irapa, which among other things means ’parallel with’. 

Paramorphisms can be expressed as catamorphisms by letting the recursive call 
return its intended result, tupled with its argument. Here, we study them as a 
separate recursion pattern however. 



5.1 The List Paramorphism 

The list paramorphism follows the recursion patterns of the following diagram. 



/ \ 

x,[x] 

I 

x,[x],u 

\ / 



destruct [x] 



recurse 



construct u 



Its implementation is straight-forward, just supply the tail 1 as an additional 
argument to the constructor function f. 



> type List_para x u = (u, x -> [x] -> u -> u) 



> list_para : : List_para x u -> [x] -> u 

> list_para (a,f) = para where 

> para [] = a 

> para (x:l) = f x 1 (para 1) 



5.2 Insert As Paramorphism 

The insertion operation insert x of the insertion sort from Sect. 2.4 can be 
expressed as a paramorphism. First we analyze its recursive structure. 



a : 1 


H 


1 1 


m 


1 1 



X : a : 1 



a : insert x 1 



insert x 1 

if X < a. 
otherwise 



destruct 

recurse 

combine 
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The list a:l is split into head a and tail 1. Recursively, x is inserted into 
1. Depending on where x < a, we need to use the original tail, or the recursive 
result. 

Although it may seem inefficient to construct the recursive result and then op- 
tionally throw it away again, laziness comes to help here. If the recursive result 
is not used, it is simply not computed. 



> insertion_sort ’ 1 = list_cata ([], insert) 1 where 

> insert x = list_para ( [x] , combine) where 

> combine a 1 rec I x < a = x : a ; 1 

> I otherwise = a : rec 



5.3 Remove As Paramorphism 

The selection operation remove x of the straight selection sort from Sect. 2.5 can 
be expressed as a paramorphism as well. First we analyze its recursive structure. 



y : 1 




1 1 


m 


1 1 



remove x 1 



1 



y : remove x 1 



X == y 
otherwise 



destruet 

recurse 

f 



It destructs the list into the head y and tail 1. It recursively removes x from 1. 
Next, it chooses between using the non-recursive tail 1 (when x == y, it suffices 
to remove y), or, in the other case, to maintain y and use the recursive result. 

Below, we give the paramorphic version of the straight selection sort algorithm. 
Observe that minimum has been written as a catamorphism. 



> straight_selection_sort ’ 1 = selection_sort extract 1 where 

> extract 1 = (m, remove ml) where m = minimum 1 

> minimum (x:l) = list_cata (x,min) 1 

> remove x = list_para ([],f) where 

> f y 1 I'sc I X == y =1 

> I otherwise = y : rec 



20 



Lex Augusteijn 



6 Generalizing Data Strnctures 

The previous sections have shown that the use of patterns of recursion gives rise 
to a classification of sorting algorithms. One can obtain a refined taxonomy of 
sorting algorithms by introducing yet another level of generalization. This extra 
level is the generalization of data types. We illustrate this by generalizing the 
binary tree data type to the rose tree data type. This type is eqnivalent to the 
so called S-trees in [8], where they are used for searching. 

> data RoseTree a = RoseTree [a] [RoseTree a] 



A binary tree has 1 element and 2 branches, a rose tree n elements and m 
branches. The empty rose tree is represented by the m = n = 0 case. Since 
qnicksort is a hylomorphism on binary trees, a hylomorphism on rose trees is 
expected to be a generalization of qnicksort. The rose tree hylomorphism is given 
by the following diagram and definition. 



u 

I 

■]> [u 

I 

:],[v 

I 



destruct u 
recurse 
construct v 



> type Rosetree_alg x v = [x] -> [v] -> v 

> type Rosetree_coalg u x = u -> ( [x] , [u] ) 

> type Rosetree_hylo u x v 

> = (Rosetree_coalg u x, Rosetree_alg 



X v) 



> rosetree_hylo : : Rosetree_hylo u x v -> u -> v 

> rosetree_hylo (f,g) = hylo where 

> hylo t = g X (map hylo 1) where (x,l) = f t 



6.1 Generalizing Quicksort 

The generalization of quicksort can be obtained by using n pivots, rather than 
1. These n pivots are sorted, e.g. by insertion_sort for small n, and the re- 
maining elements are grouped into n-|- 1 intervals w.r.t. the pivots. I.e. the first 
internal contains all elements less than the first pivot, the second internal con- 
tains all remaining elements less than the second pivot, etc., while the n + 1-th 
interval contains all elements not less than the n-th pivot. These intervals are 
sorted recursively, and the intervals and pivots are joined together. The following 
diagram illnstrates this process. 
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xs ++ 1’ 



Xl . . .x„ 




lo 






Xl . . .x„ 




So 



So++ [xi] ++Sl + +... + +[x„] ++s„ 



break 

sort recursively 
join 



The implementation is relatively straight-forward after this design. The case 
where 1== [] needs to be treated specially to ensure termination. First, 1 is split 
into its first (at most) n elements xs and the remainder 1 ’ . Next xs is sorted to 
obtain sx. Then 1’ is split w.r.t. to sx. 

> rose_sort n 1 = rosetree_hylo (break, join) 1 where 

> break [] = ([],[]) 

> break 1 = (sx, split sx lO where 

> (xs,lO = take_drop n 1 

> sx = insertion_sort xs 

> split sx 1 = list_cata ([l],f) sx where 

> fx(a:l)=s:g:l where (s,g) = partition (<x) a 

> join xs [] = xs 

> join xs (s:l) = s++concat (zipWith (:) xs 1) 

> take_drop 0 1 = ([],!) 

> take_drop n [] = ([],[]) 

> take_drop n (x:l) = (x:a,b) where (a,b) = take_drop (n-1) 1 

Experiments show that this algorithm behaves superior to the quick_sort 
function when applied to random list of various sizes. The optimal value of n 
appears to be independent of the length of the list (it equals 3 in this imple- 
mentation). A decent analysis of the complexity of this algorithm should reveal 
why this is the case. The split size can be adapted to the length of the list L 
by replacing n by some function of L. It is an open problem which function will 
give the best behavior. 

Since rose trees can be viewed as a generalization of linear lists, binary trees 
and leaf trees together, the other sorting algorithms generalize as well. E.g. the 
two-way merge sort becomes a fc-way merge sort. We leave this generalization 
as an exercise to the reader. 



6.2 Generalizing Heap Sort 

Heap sort can be generalized by means of rose trees as well. The obvious way is 
to define a heap on rose trees, instead of binary trees, construct the tree from a 
list and map it onto a sorted list. 
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The empty heap is represented by Rosetree [] [] , the non-empty heap by 
Rosetree [x] 1, where x is the minimum element and 1 a list of heaps. We aim 
at keeping 1 balanced, that is, let the sub heaps vary in sizes as little as possible, 
to obtain a good worst-case behavior. 

This variant of heap sort is known in the literature as pairing sort [5] . 



> pairingSort 1 = (rose21ist . list2rose) 1 



The function rose21ist is a variant of heap21ist. Instead of combining two 
heaps into a new heap, it should combine (meld) a list of heaps into heap, we 
postpone the treatment of this function rosesjneld. 



> rose21ist : : (Qrd a) => RoseTree a -> [a] 

> rose21ist = list_ana destruct where 

> destruct (RoseTree [] ts) = Left () 

> destruct (RoseTree [a] ts) = Right (a, roses_meld ts) 



Mapping a list into a heap is simple if we use the postponed function 
rosesjneld. 

> list2rose : : (Ord a) => [a] -> RoseTree a 

> list2rose = roses_meld . map single where 

> single a = RoseTree [a] [] 

The function rosesjneld can be designed best by first defining a function 
that melds two heaps onto a new heap. This is the rose tree variant of the 
function combine from Sect. 4.5. 



> rose_meld : : Ord a => RoseTree a -> RoseTree a -> RoseTree a 

> rose_meld (RoseTree [] _) u = u 

> rose_meld t (RoseTree [] _) = t 

> rose_meld t@(RoseTree [a] ts) u@(RoseTree [b] us) 

> I a < b = RoseTree [a] (u:ts) 

> I otherwise = RoseTree [b] (t:us) 

The function rosesjneld is now a simple list catamorphism over rosejneld. 
Implementing it that way has one draw-back however: it is not balanced. A list 
catamorphisms groups the elements together in a linear way. If the combining 
function is associative, the grouping can take place in a tree-shaped way as well, 
giving a balanced heap. We call this form of folding a list of values into a single 
value treefold and it is a leaf-tree hylomorphism. 
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z\ ... z\ 






split 



A... A A... A 



recursively build two heaps 



A A 



meld 



A 



> roses_meld : : Qrd a => [RoseTree a] -> RoseTree a 

> roses_meld = treefold rose_meld no_roses 

> treefold : : (a -> a -> a) -> a -> [a] -> a 

> treefold f e 1 = leaftree_hylo (select , (id,f) ) 1 where 

> select [] = Left e 

> select [a] = Left a 

> select 1 = Right (split 1) 

> no_roses = RoseTree [] [] 



7 Conclusions 

We have shown that it is possible to express the most well-known sorting al- 
gorithms as functional programs, using fixed patterns of recursion. Given such 
a pattern of recursion there is little or no additional design freedom left. The 
approach shows that functional programming in general and the study of re- 
cursion patterns in particular form a powerful tool in both the characterization 
and derivation of algorithms. In this paper we studied the three data types lin- 
ear lists, binary trees and binary leaf trees. Generalizing these data types to 
rose trees revealed a generalization of quick-sort, which is, as far as the author 
knows, a novel sorting algorithm. It may well be that other data types, and 
their corresponding recursion patterns, can be used to derive even more sorting 
algorithms. 

By distinguishing a hierarchy of data structures on the one hand, and dif- 
ferent patterns of recursions on the other hand, a taxonomy of algorithms can 
be constructed. It would be nice to compare this with other techniques for con- 
structing algorithm taxonomies as e.g. presented in [10]. 

Of course, other algorithms than sorting can be classified by means of their 
pattern of recursion. See e.g. [1], where similar techniques were used to charac- 
terize parsing algorithms. 

The question whether the presentation of the algorithms as such is clari- 
fied by their expression in terms of morphisms has not been raised yet. When 
we compare the catamorphic version of insertion sort to the following straight 
implementation, the latter should be appreciated over the first. 



24 



Lex Augusteijn 



insertion_sort [] = [] 

insertion_sort (x:l) = insert x (insertion_sort 1) where 
insert x [] = [x] 

insert x (a:l) I x < a = x :a:l 

I otherwise = a : insert x 1 

The value of this approach is not so much in obtaining a nice presentation 
or implementation of some algorithm, but in unraveling its structure. Especially 
in the case of heap sort, this approach gives a very good insight in the structure 
of the algorithm, compared for instance to [8] or [11]. 

We based the recursion patterns on the natural recursive functions over data 
types, the catamorphism, anamorphism, hylomorphism and paramorphism. This 
let to a very systematic derivation of recursion patterns. The category theory 
that underlies these morphisms was not needed in this presentation. There de- 
finition follows so trivially from the data type definition that any functional 
programmer should be able to define them. A generation of these recursion pat- 
terns by a compiler for a functional language is even more desirable; then there 
is not need at all for a programmer to write them. 
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Solutions to Exercises 

Solution to exercise 1: Write the list reversal funetion as a list eatamorphism. 
The empty list is reversed onto the empty list. The construct function takes the 
original head and the reversed tail. There only one way to combine these: append 
the head to the reversed tail. 

> revl = list_cata ([], construct) where 

> construct x r = r++ [x] 

Solution to exercise 2: Write a prime number generator as a list anamorphism. 
We will filter a list of prime candidates onto a list of primes. The head p of the 
candidate list is a prime, which will be the head of the result. The multiples of 
p are removed from the tail, which is recursively mapped onto a list of primes. 

> primes = sieve [2..] 

> sieve = list_ana destruct where 

> destruct (p:l) = Right (p, [ x I x <- 1, x ‘rem‘ p /= 0 ] ) 

Solution to exercise 3: Write the function as a list hylomorphism. 

We destruct an integer n onto a list of n m’s, which is than folded by the cata- 
morphism part of the hylomorphism onto the product of the’s n x’s. 

> power X = list_hylo (destruct, (!,(*))) where 

> destruct 0 = Left () 

> destruct n = Right (x,n-l) 

Solution to exercise f: Write the factorial function as a leaf-tree hylomorphism. 
A tree hylomorphism contains two recursive calls. We therefore choose to com- 
pute the product of the interval (1, n) which can be recursively split into halves. 



> tree_fac n = leaftree_hylo (destruct, (id,(*))) (l,n) where 

> destruct (a,b) 

> I a > b = Left 1 

> I a == b = Left a 

> I otherwise = Right ((a,m), (m+l,b)) where m = (a+b)/2 
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Solution to exercise 5: Write the function a;” as a leaf-tree hylomorphism. What 
is its complexity? Can you write it as a hylomorphism with O(logn) complexity? 

The exponent n can be divided by 2 and the recursive results can be multiplied. 



> pow2 X = leaf tree_hylo (destruct , (id, (*) ) ) where 

> destruct 0 = Left 1 

> destruct 1 = Left x 

> destruct n I even n = Right (n/2,n/2) 

> I otherwise = Right (n/2,n/2+l) 

The complexity is 0(n), since the hylomorphism has no information about 
the two recursively being identical. This can be fixed by using a list hylomor- 
phism, that uses only one recursively call and squaring the result of that call. 
We need an addi tional factor x in the case of n being odd. 

> pow3 X = list_hylo (destruct, (1 , construct) ) where 

> destruct 0 = Left () 

> destruct n I even n = Right (l,n/2) 

> I otherwise = Right (x,n/2) 

> construct yp=y*p*p 

Solution to exercise 6: Write the factorial function as a binary tree hylomor- 
phism. 

Again, we split the the interval (!,«.) recursively in halves. Since we not only 
need two sub-intervals, but also an additional value (as required by the binary 
tree structure), we use the middle value of the interval for that. 

> btree_fac n = 

> bintree_hylo (destruct, (1 , construct) ) (l,n) where 

> construct m x y = m*x*y 

> destruct (a,b) 

> I a > b = Left () 

> I otherwise = Right (m, (a,m-l) , (m+l,b)) where 

> m = (a+b)/2 

Solution to exercise 1: Write the function a;” as a binary tree hylomorphism. 
What is its complexity? 

This solution is close the leaf-tree solution. It split n into halves and use the 
remainder as the addtional binary tree value. The complexity is 0{n), as the 
tree hylomorphism has no idea about its two recursive calls being equal. Observe 
that this solution is very close to the linear list hylomorphism of complexity 
(D(logn). In general, a binary-tree hylomorphism with equal recursive calls can 
be rewritten into a linear list hylomorphism with improved complexity. 
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> pow4 X = bintree_hylo (destruct , (1 , construct) ) where 

> destruct 0 = Left () 

> destruct n I even n = Right (l,n/2,n/2) 

> I otherwise = Right (x,n/2,n/2) 

> construct ypq=y*p*q 

Solution to exercise 8: Write the towers of Hanoi as a binary tree hylomorphism. 
The towers of Hanoi has a natural binary tree-shaped solution: 
hanoi 0 a b c = [] 

hanoi n a b c = hanoi (n-1) a c b ++ 

[a++"-"++c] ++ 
hanoi (n-1) b a c 

This is easily written as a hylomorphism: 

> hanoi = bintree_hylo (destruct, ([], construct) ) where 

> construct m 1 r = 1 ++ [m] ++ r 

> destruct (0,a,b,c) = Left () 

> destruct (n,a,b,c) = 

> Right (a++"-"++c, (n-l,a,c,b), (n-l,b,a,c)) 

> h_test n = hanoi (n, "a" , "b" , "c") 

Solution to exercise 9: Write the function partition as a list catamorphism. 
The empty list is mapped onto the pair of empty lists, ([],[]). the tail of a non- 
empty list is recursively mapped onto a pair of lists, and the head is prepended 
to the left of these in case of p and to the right otherwise. Observe that the 
fuction definition below is much shorter than this description in English. 

> partition p 1 = list_cata (([],[]),f) 1 where 

> f X (a,b) = if p X then (x:a,b) else (a,x:b) 
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1 Introduction 

1.1 The Abstraction-Specialisation Cycle 

The development of science proceeds in a cycle of activities, the so-called ab- 
straction-specialisation cycle. Abstraction is the process of seeking patterns or 
commonalities, which are then classified, often in a formal mathematical frame- 
work. In the process of abstraction, we gain greater understanding by eliminating 
irrelevant detail in order to identify what is essential. The result is a collection of 
general laws which are then put to use in the second phase of the cycle, the spe- 
cialisation phase. In the specialisation phase the general laws are instantiated to 
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specific cases which, if the abstraction is a good one, leads to novel applications, 
yet greater understanding, and input for another round of abstraction followed 
by specialisation. 

The abstraction-specialisation cycle is particularly relevant to the development of 
the science of computing because the modern digital computer is, above all else, 
a general-purpose device that is used for a dazzling range of tasks. Harnessing 
this versatility is the core task of software design. 

Good, commercially viable, software products evolve in a cycle of abstraction and 
customisation. Abstraction, in this context, is the process of identifying a single, 
general-purpose product out of a number of independently arising requirements. 
Customisation is the process of optimizing a general-purpose product to meet 
the special requirements of particular customers. Software manufacturers are 
involved in a continuous process of abstraction followed by customisation. 

1.2 Genericity in Programming Languages 

The abstraction-specialisation/customisation cycle occurs at all levels of soft- 
ware design. Programming languages play an important role in facilitating its 
implementation. Indeed, the desire to be able to name and reuse “programming 
patterns” — capturing them in the form of parametrisable abstractions — has 
been a driving force in the evolution of high-level programming languages to the 
extent that the level of “genericity” of a programming language has become a 
vital criterion for usability. 

To determine the level of genericity there are three questions we can ask: 

— Which entities can be named in a definition and then referred to by that 
given name? 

— Which entities can be supplied as parameters? 

— Which entities can be used “anonymously” , in the form of an expression, as 
parameters? (For example, in y = sin(2 xa:), the number resulting from 2 x 
X is not given a name. In a language allowing numeric parameters, but not 
anonymously, we would have to write something like y = sin(x) where z = 
2 X X.) 

An entity for which all three are possible is called a Grst-class citizen of that 
language. 

In one of the first high-level programming languages, Fortran (1957), proce- 
dures could be named, but not used as parameters. In Algol 60 procedures 
(including functions) were made almost first-class citizens: they were allowed 
as parameters, but only by name. In neither language could types be named, 
nor passed as parameters. In Algol 68 procedures were made true first-class 
citizens, making higher-order functions possible (but not practical, because of 
an awkward scope restriction^). Further, types could be named, but not used as 
parameters. 



^ Anything that — in implementation terms — would have required what is now known 
as a “closure”, was forbidden. 
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Functional programming languages stand out in the evolution of programming 
languages because of the high-level of abstraction that is achieved by the combi- 
nation of higher-order functions and parametric polymorphism. In, for example, 
Haskell higher-order functions are possible and practical. But the level of gener- 
icity still has its limitations. Types can be defined and used as parameters, but 
. . . types can only be given as parameters in “type expressions” . They cannot 
be passed to functions. The recent Haskell-like language Cayenne [2] which ex- 
tends Haskell with dependent types does allow types as arguments and results 
of functions. 

In these lecture notes we introduce another dimension to the level of abstraction 
in programming languages, namely parameterisation with respect to classes of 
algebras of variable signature. This first chapter is intended to introduce the key 
elements of the lectures in broad terms and to motivate what is to follow. We 
begin by giving a concrete example of a generic algorithm. (The genericity of 
this algorithm is at a level that can be implemented in conventional functional 
programming languages, since the parameter is a class of algebras with a fixed 
signature.) This is followed by a plan of the later chapters. 



1.3 Path Problems 

A good example of parameterising programs by a class of algebras is provided 
by the problem of finding “extremal” paths in a graph. 

Extremal path problems have as input a finite, labelled graph such as the one 
shown below. 




Formally, a directed graph consists of a finite set of nodes, V, a finite set of edges, 
E, and two functions source and target, each with domain E and range V. If 
source e is the node x and target e is the node y, we say that e is from x to y. (In 
the figure the nodes are circled and an edge e is depicted by an arrow that begins 
at source e and points to target e.) A path through the graph from node s to node 
t of edge length n is a finite list of edges [ei, C 2 , . . . , e„] such that s = source ci 
and t = target e„ and, for each i, 0 < i < n, target Ci = source Ci+i. A graph is 
labelled if it is supplied with a function label whose domain is the set of edges, E. 
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In an extremal path problem the edge labels are used to weight paths, and 
the problem is to find the extreme (i.e. best or least, in some sense) weight of 
paths between given pairs of nodes. We discuss three examples: the reachability 
problem, the least-cost path problem and the bottleneck problem. 

Reachability The reachability problem is the problem of determining for each 
pair of nodes x and y whether there is a path in the graph from x to y. It is 
solved by a very elegant (and now well-known) algorithm discovered by Roy [42] 
and Warshall [46] . The algorithm assumes that the nodes are numbered from 1 
to N (say) and that the existence of edges in the graph is given by an NxN 
matrix a where is true if there is an edge from node numbered i to the node 
numbered j, and false otherwise. The matrix is updated by the following code. 
On termination aij is true if there is a path from node i to node j of edge length 
at least one; otherwise is false. 

for each k, 1 < k < N 
do for each pair (i,j), 1 < i,j < N 
do Qij . — aij V {ai]^ A aj^j^ 

end_for 

end_for 

(The order in which the nodes are numbered, and the order in which pairs of 
nodes (*,j) are chosen in the inner loop, is immaterial.) 

The reachability problem is an extremal path problem in which all edges have 
the same label and all paths have the same weight, namely true. 

Least- Cost Paths About the same time as Warshall’s discovery of the reachability 
algorithm, Floyd [17] discovered a very similar algorithm that computes the cost 
of a least cost path between each pair of nodes in the graph. The algorithm 
assumes that the matrix a is a matrix of numbers such that represents the 
least cost of traversing an edge from node i to node j. If there is no edge from i 
to j then Qij is oo. The cost of a path is the sum of the costs of the individual 
edges on the path. Floyd’s algorithm for computing the cost of a least cost path 
from each node to each other node is identical to the Roy- Warshall algorithm 
above except for the assignment statement which instead is: 

aij . — aij (uifc af^j') 

where x y denotes the minimum of x and y. 

Bottleneck Problem A third problem that can be solved with an algorithm of 
identical shape to the Roy- Warshall algorithm is called the bottleneck problem. 
It is most easily explained as determining the best route to negotiate a high 
load under a series of low bridges. Suppose an edge in a graph represents a road 
between two cities and the label is the height of the lowest underpass on the 
road. The height of a path between two nodes is defined to be the minimum 
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of the heights of the individual edges that make up the path. The problem is 
to determine, for each pair of nodes i and j, the maximum of the heights of 
the paths from node i to node j (thus the maximum of the minimum height 
underpass on a path from i to j). 

The bridge height problem is solved by an algorithm identical to the Roy- 
Warshall algorithm above except for the assignment statement which in this 
case is: 



dij : — dij b {dik b dkj') 

where x ^ y denotes the minimum of x and y and x y denotes their maximum. 
(In the case that there is no edge from i to j then the initial value of is 0.) 

A Generic Path Algorithm If we abstract from the general shape of these three 
algorithms we obtain a single algorithm of the form 

for each k, 1 < k < N 
do for each pair {i,j), 1 < i,j < N 
do Uij := a^J © (d^k'^dkj) 

end_for 

end_for 

where ® and © are binary operators. The initial value of is the label of the 
edge from i to j if such an edge exists, and is a constant 0 otherwise. (For the 
purposes of exposition we assume that there is at most one edge from i to j for 
each pair of nodes i and j.) The algorithm is thus parameterised by an algebra. 
In the case of the Roy-Warshall algorithm the carrier of the algebra is the two- 
element set containing true and false, the constant 0 is false, the operator © is 
disjunction and the operator © is conjunction. In the case of the least-cost path 
problem the carrier is the set of positive real numbers, the constant 0 is oo, the 
operator © is the binary minimum operator, and the operator © is addition. 
Finally, in the case of the bridge height problem the carrier is also the set of 
positive real numbers, the operator © is the binary maximum operator, and the 
operator © is minimum. 

Correctness The above generic algorithm will compute “something” whatever 
actual parameters we supply for the formal parameters ©, © and 0, the only 
proviso being that the parameters have compatible types. But, that “something” 
is only guaranteed to be meaningful if the operators obey certain algebraic prop- 
erties. The more general transitive closure algorithm shown below 

for each k, 1 < k < N 
do for each pair (i,j), 1 < i,j < N 
do a^j := dij © {difi; © (ufcfc) © 

end_for 

end_for 




